10/698,568 



MS30605 1 .01/MSFTP506US 



Remarks 

Claims 1-6, 8, 9, 11-14, 16, and 26-32 are currently pending in the subject application 
and are presently under consideration. Claim 1 has been amended as shown on p. 2 of the Reply. 

Favorable reconsideration of the subject patent application is respectfully requested in 
view of the comments and amendments herein. 

I. Rejection of Claim 1 Under 35 U.S.C $112 

Claim 1 stands rejected under 35 U.S.C §112, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. Claim 1 has been amended to overcome the rejection under 35 U.S.C. §1 12, 
second paragraph. Accordingly, withdrawal of the claim rejections and allowance of this claim 
is respectfully requested. 

II. Rejection of Claims 1-6. 8-9. 11-14. 16 and 26-32 Under 35 U.S.C. $ 102(b) 

Claims 1-6, 8-9, 1 1-14, 16 and 26-32 stand rejected under 35 U.S.C. § 102(b) as being 
anticipated by Abdelaziz et al. (US Pat. 7,197,565), hereinafter Abdelaziz. Claims 1 and 26 are 
independent claims. Reconsideration and withdrawal of the rejection of claims 1 and 26 (and 
associated dependent claims 2-6, 8-9, 1 1-14, 16, and 27-32) under 35 U.S.C. § 102(b) is 
respectfully requested in view of the comments below. 

For a prior art reference to anticipate, 35 U.S.C. §102 requires that 
"each and every element as set forth in the claim is found, either 
expressly or inherently described, in a single prior art reference." 
In re Robertson, 169 F.3d 743, 745, 49 USPQ2d 1949, 1950 (Fed. 
Cir. 1999) (quoting Verdegaal Bros., Inc. v. Union Oil Co., 814 
F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 1987)) (emphasis 
added). 

Applicant's invention provides target object presence tracking that employs multicast- 
type messages transmitted in unicast to detect such target objects, where the messages are of a 
multicast type but are transmitted in unicast to a specific object, rather than to multiple objects as 
would be the case for traditional multicast messaging. As an example, the Universal Plug and 
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Play specification (UPnP) specifies an M-SEARCH verb that allows a UPnP client application to 
search for UPnP devices. See, e.g., p.2, 11. 19-20. Rather than sending such a multicast type 
messages as a multi-cast datagram, in accordance with an aspect of applicant's claimed 
invention, it is possible to send such M-SEARCH verbs as unicast datagrams to a specific 
destination device. See, e.g., p.2, 11. 25-26. The destination device can receive the M-SEARCH 
verb on its port and can treat the multicast-type message as if it was a search request broadcast to 
all devices. See, e.g., p.2, 11. 26-28. As a result, applicant's invention provides target object 
presence tracking that employs multicast-type messages (e.g., such as M-SEARCH verbs) 
transmitted in unicast to detect such target objects (e.g., send the normally utilized multicast- 
type message only to the one target object) to prompt a response from the selected target object. 
See, e.g., ^.9, 11. 25-29. 

For example, a destination device can receive an M-SEARCH verb on its port and can 
treat the multicast-type message (sent as a unicast datagram) as if it was a search request 
broadcast to all devices. See p. 6, 11. 25-30. The device responds with a directed search response. 
Id. Thus, the response is similar to that for a multicast message, because it can be treated as if it 
was a response to a multicast message. As a further example, a destination device 404 can 
receive the M-SEARCH verb on its port and, believing it to be a general request for the device 
(e.g., a multicast message), can treat it as if it was a broadcast M-SEARCH request (e.g., a 
multicast message). The device 404 can then respond with a proper directed search response of 
"200 OK" (e.g., a unicast response) indicating that it is on-line. Thus, whereas a proper response 
of "200 OK" to a broadcast M-SEARCH request (e.g., a multicast message) is performed, the 
response is similar to that for a multicast message in that the response of "200 OK" is sent 
similar to a response for a multicast request. 

As a further example, referring to Figure 3D, there is illustrated a sample UPnP protocol 
stack 328 used to send a multicast-type discovery datagram in unicast in accordance with the 
present invention. See, e.g., p. 14, 11. 26-28. The layers 302 and 304 are hosted in UPnP-specific 
protocols by the device architecture layer 306. See, e.g., p.14, 1. 31 to p. 15, 1. 3. Here the 
discovery request is delivered via a unicast variant of an HTTP layer 330 that uses an extension 
using SSDP methods headers. Id. The discovery response is delivered via a unicast variant of an 
HTTP layer 332 that has also been extended with SSDP. Id. The UDP layer 314 indicates that 
the HTTP data (330 and 332) is delivered via UDP over IP, as further indicated by the layer 318. 
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Id. Referring to Figure 4, there is illustrated a flow diagram 400 between a UPnP client 
application 402 and a UPnP device 404 when the UPnP device 404 comes on-line. See, e.g., 
p.15, 11. 4-6. For discovery, the client 402 can use a GENA NOTIFY verb (multicast-type 
message) transmitted over the HTTP protocol as described. Id. 

In contrast, Abdelaziz merely discloses a decentralized mechanism for detecting the 
presence of entities in a peer-to-peer networking environment. To that end, Abdelaziz discloses 
the notion of a communications channel as a pipe for an entity on a peer node. Thus, pipes are 
described as providing the primary channels for communication among peers and a mechanism 
for establishing communication between peers. Abdelaziz further describes pipes used as 
communication channels for sending and receiving messages between services or applications 
over peer endpoints. Communicating over the pipe may include sending messages formatted in 
accordance with one or more peer-to-peer platform protocols over the pipe. Messages define an 
envelope to transfer any kinds of data. 

Thus, Abdelaziz describes generating a unique identifier that is assigned to the peer-to- 
peer network entity and pipe advertisement for a peer-to-peer network entity for peer-to-peer 
presence detection. Accordingly, a pipe advertisement describing the entity and the pipe and 
corresponding to the unique identifier of the entity may be generated as the identity of the entity. 
In addition, the entity may be moved or otherwise migrate to one or more other peer nodes to be 
hosted by the other peer nodes. However, Abdelaziz fails to disclose aspects of applicant's 
claimed invention. 

In this regard, independent claims 1 and 26 facilitates determining the presence of an 
object on a network. In particular, independent claims 1 and 26 recite the similar limitation: 
transmitting a multicast-type message in unicast to the object. Figure 15 and column 28, lines 
15-23 are cited for support that Abdelaziz discloses transmitting a multicast-type message in 
unicast to the object. However, the indicated portions, as well as throughout the cited reference, 
fail to disclose this aspect of applicant's claimed invention. 

For example, column 28, lines 15-23 describe pipes as being indiscriminate (may support 
binary code, data strings, Java technology-based objects, and/or applets, among others). 
Abdelaziz describes that any number of unicast and multicast protocols and algorithms, and 
combinations thereof, may be used. Id. Applicant's representative respectfully submit that 
allowing for any number of unicast and multicast protocols to be used, or combinations thereof, 
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does not expressly or inherently describe transmitting a multicast-type message in unicast to 
the object to determine presence of an object as applicant's claim. 

As a further example, Abdelaziz' Figure 15 depicts using messages to discover 
advertisements. As described above, communicating over the pipe may include sending 
messages formatted in accordance with one or more peer-to-peer platform protocols over the 
pipe. However, "[r]egardless of transport, messages may be unicast (point to point) between two 
peers or may be propagated (like a multicast) to a peer group." See Col. 34, 11. 46-48 (emphasis 
added). Thus, as depicted in Figure 15, Abdelaziz describes messages used to discover 
advertisements either with "(propagate message 230) or alternatively a rendezvous peer (a 
unicast message 232). See Col. 73, 11. 22-24 (emphasis added). Accordingly, applicant's 
representative respectfully submits that using either multicast messages or unicast messages 
does not explicitly or inherently disclose transmitting a multicast-type message in unicast to the 
object to determine presence of an object as applicant's claim. Reconsideration and withdrawal 
of the rejection of claims 1 and 26 (and associated dependent claims 2-6, 8-9, 11-14, 16, and 27- 
32) under 35 U.S.C. § 102(b) is respectfully requested in view of the comments above. 

Moreover, claim 1 as previously amended recites "the object having ... a plurality of 
functions capable of independent presence indication associated therewith and ... if a response 
is not received, the object is presumed to be off-line with respect to the first set of one or more of 
the plurality of functions, the object is presumed to be on-line with respect to a second set of one 
or more of the plurality of functions . . . ." Because Abdelaziz is silent with respect to such 
functionally granular presence detection, Abdelaziz cannot be said to explicitly or inherently 
disclose this aspect of the claimed invention. On this additional basis, the rejection of 
independent claim 1 (and associated dependent claims 2-6, 8-9, 1 1-14, and 16) under 35 U.S.C. § 
102(b) should be withdrawn. 

In response to arguments, it is submitted that Abdelaziz discloses transmitting a 
multicast-type message in unicast, multicast, or a combination to the object. Thus, it is concluded 
that Abdelaziz encompasses transmitting a multicast-type message in the unicast to the requested 
object. Applicant's representative respectfully disagrees. It is noted that no support in Abdelaziz 
is offered to support this conclusion. Thus, as described above, applicant's representative 
respectfully submits that using either multicast messages or unicast messages or a combination 
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still fails to explicitly or inherently disclose transmitting a multicast-type message in unicast to 
the object to determine presence of an object as applicant's claim. 

Accordingly, reconsideration and withdrawal of the rejection of claims 1 and 26 (and 
associated dependent claims 2-6, 8-9, 1 1-14, 16, and 27-32) under 35 U.S.C. § 102(b) is 
respectfully requested in view of the foregoing comments. 
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Conclusion 

The present application is believed to be in condition for allowance in view of the above 
comments and amendments. A prompt action to such end is earnestly solicited. 

In the event any fees are due in connection with this document, the Commissioner is 
authorized to charge those fees to Deposit Account No. 50-1063 [MSFTP506US]. 

Should the Examiner believe a telephone interview would be helpful to expedite 
favorable prosecution, the Examiner is invited to contact applicants' undersigned representative 
at the telephone number below. 



Respectfully submitted, 
Amin, Turocy & Calvin, llp 



/Himanshu S. Amin/ 
Himanshu S. Amin 
Reg. No. 40,894 



Amin, Turocy & Calvin, llp 
24 th Floor, National City Center 
1900 E. 9 th Street 
Cleveland, Ohio 44114 
Telephone (216) 696-8730 
Facsimile (216) 696-8731 
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